{"is_final":false,"mode":"2pass-offline","stamp_sents":[{"end":2270,"punc":"，","start":430,"text_seg":"正 是 因 为 存 在 绝 对 正 义","ts_list":[[430,670],[670,810],[810,1030],[1030,1130],[1130,1330],[1330,1510],[1510,1670],[1670,1810],[1810,1970],[1970,2270]]},{"end":4535,"punc":"","start":2270,"text_seg":"所 以 我 们 接 受 现 实 的 相 对 正 义","ts_list":[[2270,2389],[2389,2490],[2490,2570],[2570,2709],[2709,2969],[2969,3310],[3310,3570],[3570,3730],[3730,3830],[3830,3969],[3969,4150],[4150,4270],[4270,4535]]}],"text":"正是因为存在绝对正义，所以我们接受现实的相对正义","timestamp":"[[430,670],[670,810],[810,1030],[1030,1130],[1130,1330],[1330,1510],[1510,1670],[1670,1810],[1810,1970],[1970,2270],[2270,2389],[2389,2490],[2490,2570],[2570,2709],[2709,2969],[2969,3310],[3310,3570],[3570,3730],[3730,3830],[3830,3969],[3969,4150],[4150,4270],[4270,4535]]","wav_name":"wav_default_id"}

如上所示，目前2pass中2pass-offline的结果是支持句子级时间戳的，辛苦详细解释下你的PR，并给一些结果实例

   功能的实现原理是，在原本框架中对实时流进行vad时的结果进行时间转换，得到毫秒级别的句子相对于实时音频流开始时间的开始和结束时间，通过本身就支持的vad模型替换主模型的时间戳返回，且之后不再受主模型是否支持时间戳功能的限制。

   目前FunASR支持句子级别时间戳是指当模型本身支持句子级别时间戳时才会有相关返回，但是当模型本身并不支持时，就没有相关内容。例如，我现在使用的iic/SenseVoiceSmall-onnx主模型进行实时识别时，原本返回并没有时间戳，我自己修改完代码后，websocket返回时就带上了vad模型对实时音频流vad的时间内容。

修改后的websocket返回结果如下图所示：

   功能的实现原理是，在原本框架中对实时流进行vad时的结果进行时间转换，得到毫秒级别的句子相对于实时音频流开始时间的开始和结束时间，通过本身就支持的vad模型替换主模型的时间戳返回，且之后不再受主模型是否支持时间戳功能的限制。

   目前FunASR支持句子级别时间戳是指当模型本身支持句子级别时间戳时才会有相关返回，但是当模型本身并不支持时，就没有相关内容。例如，我现在使用的iic/SenseVoiceSmall-onnx主模型进行实时识别时，原本返回并没有时间戳，我自己修改完代码后，websocket返回时就带上了vad模型对实时音频流vad的时间内容。

修改后的websocket返回结果如下图所示：

明白了，你的PR用的是VAD的时间戳
VAD的时间戳只有句子开始、结束的时间戳，模型时间戳相对更准确，提供的是字级别的，我们评估下是否需要提供VAD的时间戳
另外，Sensevoice时间戳模型也在开发中，预计下个月放出来

方便问一下，SenseVoice的热词模型是否有计划，我们这边按照文档自训练了一下SenseVoiceSmall，发现效果很差，希望能有官方的热词版支持

方便问一下，SenseVoice的热词模型是否有计划，我们这边按照文档自训练了一下SenseVoiceSmall，发现效果很差，希望能有官方的热词版支持

热词版本目前没有计划

   功能的实现原理是，在原本框架中对实时流进行vad时的结果进行时间转换，得到毫秒级别的句子相对于实时音频流开始时间的开始和结束时间，通过本身就支持的vad模型替换主模型的时间戳返回，且之后不再受主模型是否支持时间戳功能的限制。

   目前FunASR支持句子级别时间戳是指当模型本身支持句子级别时间戳时才会有相关返回，但是当模型本身并不支持时，就没有相关内容。例如，我现在使用的iic/SenseVoiceSmall-onnx主模型进行实时识别时，原本返回并没有时间戳，我自己修改完代码后，websocket返回时就带上了vad模型对实时音频流vad的时间内容。

修改后的websocket返回结果如下图所示：

明白了，你的PR用的是VAD的时间戳 VAD的时间戳只有句子开始、结束的时间戳，模型时间戳相对更准确，提供的是字级别的，我们评估下是否需要提供VAD的时间戳 另外，Sensevoice时间戳模型也在开发中，预计下个月放出来

请问，Sensevoice时间戳模型和相关的支持代码已经有了吗？

   功能的实现原理是，在原本框架中对实时流进行vad时的结果进行时间转换，得到毫秒级别的句子相对于实时音频流开始时间的开始和结束时间，通过本身就支持的vad模型替换主模型的时间戳返回，且之后不再受主模型是否支持时间戳功能的限制。

   目前FunASR支持句子级别时间戳是指当模型本身支持句子级别时间戳时才会有相关返回，但是当模型本身并不支持时，就没有相关内容。例如，我现在使用的iic/SenseVoiceSmall-onnx主模型进行实时识别时，原本返回并没有时间戳，我自己修改完代码后，websocket返回时就带上了vad模型对实时音频流vad的时间内容。

修改后的websocket返回结果如下图所示：

明白了，你的PR用的是VAD的时间戳 VAD的时间戳只有句子开始、结束的时间戳，模型时间戳相对更准确，提供的是字级别的，我们评估下是否需要提供VAD的时间戳 另外，Sensevoice时间戳模型也在开发中，预计下个月放出来

请问，Sensevoice时间戳模型和相关的支持代码已经有了吗？

FunASR最新版本已经支持框架级别的SenseVoice字时间戳，但是目前我这边实际运用发现点问题，还不成熟

{"is_final":false,"mode":"2pass-offline","stamp_sents":[{"end":2270,"punc":"，","start":430,"text_seg":"正 是 因 为 存 在 绝 对 正 义","ts_list":[[430,670],[670,810],[810,1030],[1030,1130],[1130,1330],[1330,1510],[1510,1670],[1670,1810],[1810,1970],[1970,2270]]},{"end":4535,"punc":"","start":2270,"text_seg":"所 以 我 们 接 受 现 实 的 相 对 正 义","ts_list":[[2270,2389],[2389,2490],[2490,2570],[2570,2709],[2709,2969],[2969,3310],[3310,3570],[3570,3730],[3730,3830],[3830,3969],[3969,4150],[4150,4270],[4270,4535]]}],"text":"正是因为存在绝对正义，所以我们接受现实的相对正义","timestamp":"[[430,670],[670,810],[810,1030],[1030,1130],[1130,1330],[1330,1510],[1510,1670],[1670,1810],[1810,1970],[1970,2270],[2270,2389],[2389,2490],[2490,2570],[2570,2709],[2709,2969],[2969,3310],[3310,3570],[3570,3730],[3730,3830],[3830,3969],[3969,4150],[4150,4270],[4270,4535]]","wav_name":"wav_default_id"}

如上所示，目前2pass中2pass-offline的结果是支持句子级时间戳的，辛苦详细解释下你的PR，并给一些结果实例

请问2pass返回的2pass-online支持字级别的时间戳么，目前看到的只要识别出来的文字信息

This is a substantial change (18 files) to the runtime 2pass mode for sentence-level timestamps. The feature is valuable, but I cannot verify the C++ runtime build and behavior at this time. The PR also likely has conflicts with recent main branch changes. Please rebase against the latest main and ensure the build passes. If you can provide test results showing the timestamp output, we can reconsider merging.

Thanks for this PR. The feature (sentence-level timestamps in 2pass streaming mode) is valuable.

However, this touches 18 files in the C++ runtime and needs thorough testing with the streaming service before merge. Could you confirm:

1. Has this been tested with the latest funasr-runtime-sdk-online-cpu Docker image?
2. Are there any breaking changes to the existing WebSocket protocol?
3. Is the timestamp output format backward-compatible with existing clients?

We want to make sure this integrates cleanly with the current runtime.